\documentclass{beamer}
\usepackage[utf8]{inputenc}
\usepackage[final]{pdfpages}

\usetheme{Goettingen}%Warsaw}
\usecolortheme{lily}
\setbeamertemplate{footline}[page number]
\title[Transactional storage for geo-replicated systems ]{Transactional storage for geo-replicated systems - overview}
\author{Jander Nascimento
\and Liviu Varga}
\institute{University Joseph Fourier}
\date{\today}
\begin{document}

\begin{frame}
\titlepage
\end{frame}

%\AtBeginSubsection[]
{
  \begin{frame}<beamer>
    \frametitle{Roadmap}
    \tableofcontents%[currentsection,currentsubsection]
  \end{frame}
}

%this is filled up with some sample code (we can remove it anytime)

\section{Introduction}

	\subsection{Overview}
	
		\begin{frame}{Objective}
		
			Build scalable distributed system, improve the availability and reduce response time 
		
	\begin{figure} [H]
		\centering
		\includegraphics[scale=0.20]{img/fig_network}
	\end{figure}		
		\pause
			How this is achieved?
			\begin{enumerate}[<+->]
			\item Key-store application
			\item Asynchronous replication
			\end{enumerate}
			
		\pause			
			
			\begin{block}{Lema}
				Respecting causality order without compromise the throughput
			\end{block}
		
		\end{frame}	
			
		\begin{frame}{Already existing frameworks}
	


		
	
	\begin{columns}
	\begin{column}[1]{5cm}
	\includegraphics[width=0.5\textwidth]{img/fig_google.png}
	\end{column}
	\begin{column}[1]{5cm}
	\includegraphics[width=0.5\textwidth]{img/fig_yahoo.png}
	\end{column}
	\end{columns}
		
		
		\begin{figure} [H]
			\centering
			\includegraphics[scale=0.20]{img/fig_hp}
		\end{figure}				

			Other transaction infrastructure					
		
			\begin{enumerate}
			\item Percolator			
			\item Sinfonia
			\end{enumerate}						
				
			\pause			
			
			Other storage system
			\begin{enumerate}
			\item PNUTS
			%\item COPS
			\item Megastore
			\end{enumerate}		

		\end{frame}
	
		\begin{frame}{Dificulties?}
		
		\begin{figure} [H]
			\centering
			\includegraphics[scale=0.40]{img/fig_clock}
		\end{figure}			
		
		What are the problems faced?		
		
			%talk about sinfonia compare with other the type server that dont use transactions
		\begin{itemize}[<+->]
		\item Replication between sites
		\item Preserve consistence		
		\item Conflict resolution
		\end{itemize}
		
		\end{frame}		
	
		\begin{frame}{Parallel Snapshot idiosyncrasy}

			What is the difference between Parallel Snapshot Isolation and others?
			\begin{enumerate}
			\item Snapshot Isolation. %e.g. percolator
			\item Ignoring primary site constraint. %e.g. sinfonia
			\end{enumerate}

			\pause

			\begin{alertblock}{Is just gather things together?}
				Snapshot Isolation protocol had to be changed to support multiple site store
			\end{alertblock}
						
		\end{frame}		

\section{Walter framework}

	\subsection{Parallel Snapshot Isolation}
		\begin{frame}{Tools}
		
			Few tools are used to reach the goal
		
			\begin{itemize}[<+->]		
		
			\item\emph{CSet} (Counting Set)
			
			\item\emph{Preferred Site}
			
			\item\emph{Object Container}
			
			\end{itemize}			
			
		\end{frame}
		
		\begin{frame}{Properties}
		
		PSI as its properties:		
		
		\begin{itemize}
		\item Operations on the last snapshot
		\item Transactions must to be disjoint
		\item Transaction must respect the causality across site 
		\end{itemize}
		
		\end{frame}	


		\begin{frame}{Anomalies}		
		Storage systems side-effects
		\begin{itemize}[<+->]
		\item Dirty read
		\item Non-repeatable read
		\item Lost update
		\item Fork
		\end{itemize}		
		
		\end{frame}

		%%%% JANDER SPEACH ENDS HERE
		%%%% LIVIU STARTS HERE

	\begin{frame}{Limitations}

			\begin{enumerate}
			\item Short and long fork may happen
			\item Only a single store system per site used
			\item The Container of an object cannot be changed
			\end{enumerate}
			
	\begin{columns}
	\begin{column}[1]{5cm}
	\begin{figure}
	\includegraphics[width=1.0\textwidth]{img/fig_conflict01.png}
	\caption{Short fork}
	\end{figure}
	\end{column}
	\begin{column}[1]{5cm}
	\begin{figure}	
	\includegraphics[width=1.0\textwidth]{img/fig_conflict02.png}
	\caption{Long fork}
	\end{figure}
	\end{column}
	\end{columns}			
			
		\end{frame}
		
		\begin{frame}{Durability and Availability}
		
		Two kinds of durability can be used:
		
		\begin{itemize}
		\item Normal
		\item Disaster-safe
		\end{itemize}		
		
		\pause			
		
		In case of a full site failure which did not propagate all the transactions, the following approaches can be used:
		
		\begin{itemize}
		\item Conservative
		\item Aggressive
		\end{itemize}			
		
		\end{frame} 	
		
			 	
	\subsection{Design}
	 	
 	%talk about 	 	
	 	
		\begin{frame}{Replication}
				
		\begin{itemize}
		
		\item Synchronizing among sites uses vector timestamps
		\item Each site has a local version number indicating the number of transactions in the snapshot
		\item Across sites there is casual ordering of the events
		
		\end{itemize}
		
		\end{frame}	 	
		

		\begin{frame}{Types of transaction}
		
		\begin{itemize}[<+->]
		
		\item Fast commit: used for objects which are local to the preferred site, involving two checks (objects are unmodified since the transaction started and unlocked)
		
		\item Slow commit: the preferred site of the object if a non-local one. This involves 2-phases: all the objects are unmodified and unlocked on their site, and after that proceeds as a fast commit
		
		\end{itemize}

		\end{frame}
 	
	 	
\section{Performance}

	\subsection{Results}

	\begin{frame}{Evaluation}
	
	Experimental setup
	
	\begin{itemize}
	\item Consisted of maximum 4 machines around the world running on Amazon EC2 cloud platform as well as a private cluster
	\item Read/Write operations are performed on 100-bytes objects
	\end{itemize}	
	\pause
	Results
	\begin{itemize}
	\item Base performance was evaluated by comparing Walter with a commercial open-source database library, Berkely DB 11gR2 with comparable results
	\end{itemize}	
	
	\end{frame}	
	
	\begin{frame}{Evaluation}	
	
	\begin{figure}[H]
	\includegraphics[scale=0.6]{img/fig_evaluation01.png}
	\caption{90\% read-tx: 10\% write-tx workload}
	\end{figure}	
	
	\begin{itemize}	
	\item Read throughput is bounded by the RPC performance and scales linearly with the number of sites	
	\item Write throughput is lower than read throughput due to lock contention. 	
	\end{itemize}
	
	\end{frame}
	
	\begin{frame}{Evaluation}	
	
	\begin{figure}[H]
	\includegraphics[scale=0.45]{img/fig_evaluation03.png}
	\caption{Latency of slow commit and replication}
	\end{figure}	
	
	\end{frame}	
	
	\subsection*{Recap}
	
	\begin{frame}{Reminder}
	
		What Walter offers?	
	
		\begin{itemize}
		\item \textit{Asynchronous replication across sites}. Replication is done lazily in the background to reduce latency
		\item \textit{Efficient update}. Counting sets can be updated efficiently anywhere, while other objects can be updated efficiently at their preferred site
		\item \textit{Freedom from conflict-resolution logic}. Which is complex to developers
		\item \textit{Strong isolation within each site}. Provided by PSI.
		\end{itemize}
	\end{frame}


\section{Conclusion}

\begin{frame}{Conclusion}

		\begin{itemize}%[<+->]
		\item Walter was used to efficiently implement PSI
		\item The use of such system was demonstrated by WaltSocial and ReTwis
		\end{itemize}

\end{frame}

\begin{frame}

	\begin{block}{And.. }
	Questions?
	\end{block}

\end{frame}

\end{document}
